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Part 6: introducing the FSM concept 





By Dennis Clark 


The Parallax Boe-Bot, or Board of Edu- 
cation Robot is a simple robot made 
from a Parallax Board of Education 
(BoE) mounted on an aluminium 
frame to which two Futaba hobby ser- 
vos are mounted. These servos have 
been modified to provide continuous 
motion and have several speeds at 
which they will turn. 

The BoE has a small prototyping 
area on which several experiments can 
be done. In order to realize the fasci- 
nating potential the BoE-Bot has to 
demonstrate robotic behaviours, you 
will need to know how to program it! 
In this and the following instalments | 
will explain how to 
make the robot move 
randomly, or pur- 
posely, how to seek out 
or avoid bright light 
and how to avoid 
objects. | will also explain how to pro- 
gram your BoE-Bot in such amanner 
that all of these functions seem to be 
operating at the same time. 

Further, | will show you can get 
behaviours from your robot that you 
didn’t even program in to it! 


LINEAR EXECUTION VS. 
CONCURRENT EXECU- 
TION AND THE FINITE 
STATE MACHINE 

In a program, each statement is exe- 
cuted in sequential order, the next 
statement cannot start until the last one 
is done. When there is only one thread 
of logic running, this means that the 
program proceeds in a linear fashion, 
from start to finish. Concurrent execu- 
tion is when there is more than one 
thread of logic running at what 
appears to be the same time. "How do 
| do that?”, you may ask. In the Paral- 
lax Basic Stamp || processor you can do 
this by using independent sections of 
code, called modules or in our case, sub- 
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Figure 21. Finite State 
Machine design for a 
soda machine. 
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routines that will be called many times 
before their function is complete. In 
order to do that, you will need to keep 
track of where you are in your subrou- 
tine so that you know where to start 
up again when you return. One very 
good way to do this is called the Finite 
StateM achineor FSM for short. Because 
there are only a few different actions 
you want your subroutine to execute, 
and it does actually complete its job at 
some point, it is a finite list. There are 
several forms of FSMs, this type of 
FSM isahybrid wewill use specifically 
for robotic programming. This behav- 
iour FSM isa type of a state machine 
that returns no outputs, it merely 
changes state based on input and the 
current state. Each activity that the 
FSM engages in, is a state, unique in 
operation and distinct from all other 
states by its definition. 

If this is difficult to understand, lets 
use a sort of real world application to 
explain FSMs, the soda machine. In 
order to keep our soda machine sim- 
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ple, we will create a pretty stupid 

machine with these abilities: 

» takes only quarters 

» needs two quarters to get a soda 

$ will not give you your money back 

» does not give change, nor return 
money that isn’t a quarter 

» has Coke, Barq’s Root Beer and Fanta 
Orange soda 

$ has an infinite amount of soda and 
never runs out 


As you can see, we have eliminated all 
of the exceptions or error conditions that 
a normal soda machine could see in 
order to simplify this explanation — it’s 
artificial for a reason; we're not design- 
ing soda machines. However, do pay 
attention to exceptions and error condi- 
tions when you are designing your 
own FSM $S! Figure 21 shows a graphical 
rendering of our soda machine FSM. 
The underlined numbers in each of the 
circles are the state number for that 
state. A line with an arrow denotes a 
transition from one state to another (the 


Elektor Electronics 2/2000 


Listing 9. Linear vs FSM programming 


Linear based servo controller subroutine 


act: 
ior | ol to Ap 
pulsout LEFT, 750 
Pulsout RIGHT, 750 
pause 20 
next 
return 


arrow points the direction). If a transi- 
tion line is labelled, that label is the 
result of the transition function and 
defines the condition required for that 
change of state. An unlabelled line isa 
transition that will always occur as soon 
as the function of that state is com- 
pleted. The lines that loop back upon a 
state show iteration, or that the FSM 
remains in this state doing something 
until aterminal condition is reached, at 
which time a defined transition that is 
labelled will occur. Here we see that our 
soda machine FSM will remain in state 
Ountil two quarters have been given, at 
which point our FSM will transition to 
state 1. Here we will wait, looking at 
buttons until a selection is made. When 
a selection is made, our FSM will then 
transition to state 2, 3 or 4 depending 
on the selection made. From these ter- 
minal states, our FSM will immediately 
transition back to state 0 after complet- 
ing. This is the general process of defi- 
nition and representation for the FSMs 
that we will be using to define our BoE- 
Bot behaviours. 

Remembering where you are in 
your subroutine is called saving state 
and is essential if you are to pick up 
where you left off when last this sub- 
routine ran. Each state in our behav- 
iour FSM will be executed when its 
subroutine is called and will exit the 
subroutine when that state is com- 
pleted. Subsequent calls of that sub- 
routine will execute the next correct 
state that is defined. Why is this useful? 
Let's look at two code snippets in List- 
ing 9 that show why this can make 
your whole program run faster. Both of 
these pieces of code operate the hobby 
servos that make your BoE robot 
move, don’t worry about understand- 
ing them exactly, what this code does 
will be fully explained in due course. 
The one thing you must know is that a 
hobby servo requires that a pulse of 
1ms (millisecond) to 2 ms must be sent 
to each servo every 20 to 30 ms or the 
servo will not perform correctly. If you 
send it too often (say every 7 ms) the 
servo will jitter, if you send it too rarely 
(say every 50 ms) then the servo will 
stop. These pulses need to be repeated 
continuously, and regularly in order to 
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act 


FSM based servo controller subroutine 


if aDur > 0 then aDec 


aDur = 


pulsout LEFT, 750 
pulsout RIGHT, 750 


goto aDone 


aDec: 


aDur = 


aDone: 
return 


operate correctly, a single pulse is not 
very useful to a servo. 

The code on the left looks very sim- 
ple and fast, but looks can be deceiv- 
ing. The pulsout instructions are used 
to output a pulse of the needed width 
to turn the servos. Remember, this 
pulse needs to be repeated every 20 to 
30 milliseconds (ms) in order for the 
servo to respond properly. Also, it 
needs to have several repetitions of this 
pulse for the motor to turn and keep 
running. The pause instruction will 
cause the Stamp II to pause for 20 ms, 
each of the pulses sent will be 2 
microseconds * 750, or 1.5 ms. So, each 
pass through this for/next loop will take 
3ms + 20ms = 23 ms at least, 10 times 
through the loop will take 230 ms! 
That is almost 1/4 of a second when 
nothing else can be done! 

Now let’s look at the code on the 
right that implements a two-state FSM 
to move the servos. You can see that 
our subroutine on the right does one of 
two operations at any given time. The 
first operation is to output the pulses to 
the servos and set the aD ur variable. 
The second operation is to simply 
decrement the aD ur variable. In either 
case, after the operation has been 
accomplished we exit the subroutine. 
Each of these operations will be 
defined as a state for the act behaviour. 

We will get into more details on 
how to describe and design state 
machines for our robotic behaviours 
using examples and programs that you 
will write for your BoE-Bot in later 
instalments. 

Returning to our code samples, let’s 
figure the time spent in the subroutine 
on the left now. Since the Stamp II exe- 
cutes about 4000 lines of code a second 
this means that each instruction will 
take about 250 ws to execute. The pul- 
sout instructions will obviously take 
1.5 ms each to execute because that is 
the length of the pulse that is being 
sent. In state 1 it will take 3 ms for the 
pulsout instructions + 750 us for the 
other three instructions, which equals 
3.75 ms. In state two our second sub- 
routine will take about 750 us of 
processor time each time it is executed. 

Instead of the 230 ms of processor 


aDur - 1 


time taken by the left subroutine, we 
now will take 5*750 us + 3.75 ms = 
7.5 ms of processor time total (we are 
taking 5 turns through it after the initial 
pulse outputs remember?) to accom- 
plish the same purpose. If we only 
count a single 23 ms loop for each pass 
through the first subroutine, we will 
have saved 15.5 ms of processor time, 
which, at 4000 instructions per second 
amounts to 62 instructions that can be 
executed elsewhere and give us the 
exact same activity on our servo 
motors. If we take into account the full 
230 ms time for the left loop we save 
over 226 ms which is a whopping 904 
instructions! 

But why is this important? A robot 
does not just wander aimless around 
in its environment, it usually has some 
task to accomplish. Whether it is 
searching for a fire to put out, trash to 
pick up or for another robot to attack, 
it is doing something else more impor- 
tant than just running its motors. 
When weuse the motor driver routine 
on the left above, the robot is doing 
absolutely nothing but concentrating 
on running the motors for 230 ms. 
During this time it cannot look at a sen- 
sor, pick up trash or put out a fire. If it 
runs into something, it will just keep 
running into it until it is finished with 
that loop and can then do something 
else. Each of the other behaviours that 
we implement in our robot will be 
some activity that the robot will need 
to perform in atimely manner. It does 
us no good to detect an object to avoid 
after we have already run into it! Let’s 
assume that our robot is running the 
following behaviours, listed in lowest 
priority to highest priority, to achieve 
some objective: 


» Go North until home is found 
(chooses a direction to travel) 

» Avoid hitting anything by using IR 
proximity detection (if something is 
a danger, choose another direction) 

» If | hit something, back up and 
turn left (chooses yet another direc- 
tion to go) 

» Stop and beep when | am home 
(choose no direction at all, just stop) 

» Select the highest priority direction 
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to go and call act to implement it 


Many of these behaviours will tell the 
motors to perform some action; back- 
ing up, turning left, whatever. Each of 
these behaviours will need to refer to 
sensors in order to perform their 
actions. Each of these behaviours 
(using the system | am suggesting) will 
be Finite State M achines implemented 
in subroutines that will be called from 
within some main code loop (you will 
see some of these behaviours defined 
later on). In the motor driver routine 
act shown as the right side code snip- 
pet there is a variable aD ur defined. 
When the act FSM is first called aD ur is 
set to 5. This means that the pulsout 
instructions will be executed once, then 
the next 5 times the act subroutine is 
called it will do nothing but decrement 
aD ur and exit. This means that it will 
spend aslittle time in the subroutine as 
possible. Why is this useful? It is useful 
because act only needs to send those 
pulsout actions once every 20 to 30 ms. 
Our robot can be looking at sensors 
and selecting the next motor action 
while it is waiting to send that next 
series of pulses out. In this way, weuse 
the time it takes to read sensors and 
make dedsions in those other four sub- 
routines as the delay we must take 
between pulses we send to the servo 
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motors instead of wasting that time 
with a pause instruction! In effect, this 
makes it look like everything is hap- 
pening at the same time instead of one 
thing after the other. If we were to use 
a linear programming model instead of 
Finite State M achines to implement all 
of our behaviours and actions then we 
would not be able to look at the com- 
pass or check for an obstructing object 
until all 230 ms in the code snippet on 
the left had completed. In that time our 
robot might miss seeing the chair in 
front of it and collide with it before it 
gets a chance to change direction. 
There is nothing special about the 
number 5 chosen for aD ur either, | used 
that number as a suggested starting 
point. In reality this number is chosen 
by trial-and-error to achieve the 
smoothest timing. | started with this 
number in my own robot and as | 
added behaviours | reduced it. For 
example, with four behaviours active | 
have my act routine set aD ur to only 2. 

When we implement all of our 
behaviours as FSMs this has the effect 
of interleaving the code that needs to 
be executed in each subroutine so that 
no one behaviour needs to wait until 
the prior behaviour completes in order 
to do at least some of the work that 
needs to be done in its own routine. 
This improves our robot's response 


time to its environment. In the case of 
the act subroutine above, this results in 
a smoother motor response and 
quicker reaction to obstacles and objec- 
tives. 

Before using the Finite State 
Machine method of behaviour imple- 
mentation | would notice that my 
robot would appear to hesitate longer 
and longer as | added more and more 
complex behaviours. This FSM method 
will all but eliminate this hesitation. It 
is more complex to design and code 
than linear programming, but the 
results, | feel, merit the complexity. Try 
programming your robots both linearly 
and using FSMs, | think you will agree 
that using Finite State Machines 
improves your robot's abilities and 
allows us to get as much out of our 
Stamp II as we can! Eventually a set of 
behaviours may become so complex 
that even using FSMs will not prevent 
some hesitation, but we can do much 
more using FSMsas our programming 
mode rather than linear programming 
before that happens. 
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Next month we will continue with a method 
called Subsumptive Programming which will 
help us devdop a step-by-step plan to implement 
robotic behaviour. 
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